OpenCPN Community

Opensource Software

GNU General Public License GPL GNU Definition Open Source Initiative

Opensource Cooperation

These notes are much more important in an open community like OpenCPN. Otherwise work issues tend to be stored out of sight and we risk two or more are working on the same thing clueless of each others. Open cooperation and problem solving communication is a better way.

There is a wide range of skills & skill levels in this community. We all try to help each other, but we need to understand that this is all voluntary, and intended to be fun. We all share the common interest of supporting and creating great Chart Plotter Navigation software.

Education

We unfortunately don't have manpower to teach people programming and duplicate every piece of documentation out there.

Dave has suggested these websites for Training in C++ which is the most basic skill required. In any case they should be bookmarked and studied.

We also do not have energy, time, resources, whatever, to maintain the outdated toolchain, dependencies and know-how.

However all the build instructions are updated for the current master and that is what developers should use. Version 4.8.2 is history. (Pavel -Nohal)

Participation

There are many ways to participate in and assist this Open Source Project. Many different skills and efforts are needed.

User Participation

Language Translation: Assist by Crowdin Translation of OpenCPN and Plugins

User Manual: Assist by Editing

User Feedback: Suggestions, User Interface Suggestions, Feature Requests, Bugs
should be done exclusively via:

OpenCPN Cruiser's Forum Find or make an appropriate thread For discussion.
Tracker Sometimes called Flyspray. You must register first.

Note:

Please refrain from inserting your comments, bugs & feature requests into Alpha and Beta Testing.
This distracts the programmers from their goal, disrupts communications and the points are generally lost!
Programmers are often working on much bigger projects than the User Interface, which may be associated with support of many OS, migration to newer tools, or introducing big new features..
Let the programmers work in peace on tough problems.

Beta Tester

Beta Testing is conducted in a Real Time environment (not using Debug) by volunteer testers or end users when the development team determines the software is ready.

Any user can be a beta tester, they need to know how to install and use the software and report. Using CI tools is inappropriate for Beta Testing.

Alpha Tester

Done early on by skilled testers at the specific request of programmers who are actively creating big new features or internal optimizations. These skilled testers are asked by the programmers to help achieve the main goals of the program to get it ready for Beta Testing, using a “Debug” environment. They do not “Bug” the programmers with:

Additional feature requests.
UI changes.
Known Bugs (the programmers already know about)
Other trivia.

They debug the program using their software tools and report the actions and error codes using MSVC++ call stack, or Linux debug tools. Beta testing can only begin when the development team is sure there are no obvious bugs such as null pointer deref or other errors that can be caught through testing inside a debug environment. Beta testing begins when the development team wishes it.

Early Alpha Tester

Sometimes called “heat-seekers”. For this type of tester, using the CI products for informal alpha testing of unreleased code is very useful to the devs. The main benefit to devs is the rapid cross-platform exercise of the app, where testers bang away on the interface using their favorite workflows, and attempt to break it. Most devs don't keep current images of all 5 platforms available for extended testing, and in any case this takes a lot of time. However with the software tools below, the time spent compiling is dramatically less.

It simply must be understood that this alpha testing is ad-hoc, and is not tracked in any persistent manner. But it does advance the code-base integrity quickly.

However do not “bug” the programmers. Simply report your findings as completely as possible using the Github “Issues” section. Include any pertinent logs, screenshots or files. Do not combine issues into one post and identify the program version or date.

Programmer

Programming skills vary greatly. Some are learning, some have many years of experience.

Software Tools

Debugging see the “Compiling” pages“

Online Repositories - Free to Opensource

Github Opensource Help Getting Started OpenCPN Github Plugin Repositories
Sourceforge OpenCPN Older compiled OpenCPN
Sourceforge Packaging Data Necessary for Compiling
Sourceforge Older Plugins Older Plugins

Additional Software Tools which integrate with and push to Github - Free to OpenSource :

Travis CI “Build apps with confidence”
Appveyor “Continuous Integration solution for Windows” Docs

Programmers use these tools to setup automatic builds of the current github “head”. This involves having certain *.yml files in the main directory and requires the plugin author to have an account and enable the feature. Linux and Windows executable become available for download and testing.
OpenCPN and some plugins have TravisCI and Appeveyor enabled.
Alpha Testers working closely with Programmers can then access and download the most recent “build” without having to compile.
These tools are used for ad hoc “Alpha Testing”.
OpenCPN Programmers do not use these tools for Continuous Integration (CI) or Continuous Releases (CR) or Test Driven Development (TDD).

Further reading: AppVeyor - A good continuous integration system is a joy to behold

How to use CI Tools

Bdbcat has responded to several questions, explaining how these features should be used.

1. How to get Alpha/Beta Testers familiar with Github and locating those compiled files?

When we are actually in Beta test, we will describe the process and condition of the CI artifacts.
We may use the artifacts then, but probably not.
We have enough trouble tracking issues with one “official” Beta location.
Using the almost daily updates of CI product for Beta testing would be a nightmare.
Best to think of the usefulness of CI as we are right now: In Alpha test of some new features, some of which features are known to be incomplete or even with known heinous errors.

2. Are these eventually going to be the source for the Website Downloads page?

No. The CI artifacts result from building the current github HEAD.
This, in general, will not be the same as the in-production Release point.

Summary

Testing a CI Product is like sneaking a spoon-sip of the dinner simmering on the stove while Mom is not looking. She knows it needs salt, and is way too hot to eat yet. If you drop dead immediately, she wants to know about it. Otherwise, she wants to not hear too many comments. Wait until it comes to the table. Meanwhile, go outside and play….

Dave